-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes: #15924 - Prevent API payload from allowing tagged_vlans while interface mode is set to tagged-all #17211
Fixes: #15924 - Prevent API payload from allowing tagged_vlans while interface mode is set to tagged-all #17211
Conversation
…interface mode is set to taged-all
…er model in addition to not being able to check incoming vlans under same model.
This PR has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further action is taken. |
Per maintainer meeting, need to refactor logic to try and streamline the checks. |
…into 15924-fix-api-interface-patch-tagged-all-mode
…into 15924-fix-api-interface-patch-tagged-all-mode
…into 15924-fix-api-interface-patch-tagged-all-mode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@DanSheps I know a bit outside the scope of this issue, but we have validation here going on in 3 different spots and I think (haven't checked) if you just created an Interface model and saved it (directly in code) it would accept an invalid state for this. Would it make sense to consolidate this in the model clean or at least a common function? We should really have a code standard for this - validation in one central place. Note: Asking, if you don't think it's feasible please push back.
You cannot check the many to many relationship on the clean in the model, which is the main driver of this change. You wouldn't set the many to many field and save on the model anyways, you would need to set() or add(). Now, we could make a Mixin which handles the validation and call that from both the API and form and at least consolidate the logic there (I did briefly think about this), but the datastructure in the API and the form is slightly different. I would have preferred to do this on the database too but alas there is no way to perform the check. |
FYI: Tested this, the code between the form validation and the serializer validation is unfortunately too different to really support a common check (ex: form uses There are other differences too, I think, unfortunately, it makes more sense to just check on the serializer/form. |
After some discussion, we've decided to ship this fix in v4.2 as it doesn't quite rise to the threshold of a breaking change. I'll merge this into |
Fixes: #15924 and #17249 - Prevent API payload from allowing tagged_vlans while interface mode is set to taged-all and prevent API from allowing untagged_vlan when no 802.1q mode is set.